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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

All published ETSI deliverables shall include information which directs the reader to the above source of information. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Services and Protocols for 
Advanced Networks (SPAN). 



Endorsement notice 



The elements of Internet Engineering Task Force Request for Comments RFC 3331 apply, with the following 
modifications. 



Introduction 



The present document records the changes to the Internet Engineering Task Force (IETF) RFC 3331 [2] document. 
RFC 3331 [2] specifies an Internet standard track protocol for the backhauling of Signalling Systems No.7 (SS7) 
Message Transfer Part 2 (SS7 MTP2) User signalling messages over IP using the Stream Control Transmission Protocol 
(SCTP) (see RFC 3331 [2]). 
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Scope 



The present document specifies the requirements for the MTP2 User Adaptation layer (M2UA), when used in 
conjunction with the Stream Control Transmission Protocol (SCTP) for the transport of the Signalling System 
No. 7 (SS7) Message Transport Part 3 (MTP3) messages over the Internet Protocol (IP). The document endorses and 
constrains where relevant the SIGTRAN (IETF) RFC 3331 [2] of M2UA. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

[1] ETSI EN 300 008-1: "Integrated Services Digital Network (ISDN); Signalling System No.7; 

Message Transfer Part (MTP) to support international interconnection; Part 1 : Protocol 
specification [ITU-T Recommendations Q.701 (1993), Q.702 (1988), Q.703 to Q.706 (1993), 
modified]". 

[2] IETF RFC 3331: "Signaling System 7 (SS7) Message Transfer Part 2 (MTP2) - User Adaptation 

Layer". 

NOTE: At http://www.ietf org/rfc/rfc333 1 .txt. 

[3] ITU-T Recommendation Q.701: "Functional description of the message transfer part (MTP) of 

Signalling System No. 7". 

[4] ITU-T Recommendation Q.702: "Signalling data link". 

[5] ITU-T Recommendation Q.703: "Signalling link". 

[6] ETSI TS 102 142: "Services and Protocols for Advanced Networks (SPAN); MTP/SCCP/SSCOP 

and SIGTRAN (Messag of SS7 over IP); Message transfer part 3 User Adaptation layer (M3UA) 
[Endorsement of RFC 3332 (2002), modified]". 

[7] ETSI TS 102 143: "Services and Protocols for Advanced Networks (SPAN); MTP/SCCP/SSCOP 

and SIGTRAN (Transport of SS7 over IP); Signalling connection control part User Adaptation 
layer (SUA) [Endorsement of SIGTRAN-SUA-14 (December 2002), modified]". 

[8] ETSI TS 102 144: "Services and Protocols for Advanced Networks (SPAN); MTP/SCCP/SSCOP 

and SIGTRAN (Transport of SS7 over IP); Stream Control Transmission Protocol (SCTP) 
[Endorsement of RFC 2960 and RFC 3309, modified]". 



3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 



AS 


Application Server 


ASP 


Application Server Process 


ASPAC 


ASP Active 


ASPIA 


ASP InActive 



ETSI 



ETSI TS 102 141 VI. 1.1 (2003-05) 



ASPSM Application Server Process State Maintenance 

ASPTM ASP Traffic Management 

BEAT heartBEAT 

BEAT ACK heartBEAT ACK 

DEREG REQ DE-REGistration REQuest 

DEREG RSP DE-REGistration ReSPonse 

ERR ERroR 

lANA Internet Assigned Numbers Authority 

IETF Internet Engineering Task Force 

IIM Interface Identifier Management 

IP Internet Protocol 

M2UA Message transfer part level 2 User Adaptation layer 

MAUP MAUP 

NOTE: Is used in RFC for MTP2 User adaption. 

MGC Media Gateway Controller 

MTP Message Transfer Part 

MTP2 Message Transfer Part level 2, the signalling data link layer over SS7 

MTP3 Message Transfer Part level 3, the signalling network layer over SS7 

NTFY NoTiFY 

REG REQ REGistration REQuest 

REG RSP REGistration ReSPonse 

SCTP Stream Control Transmission Protocol 

SG Signalling Gateway 

SGP Signalling Gateway Process 

SS7 SignalHng System Number 7 



4 General considerations applicable to transport of 

Signalling System No. 7 over IP 

The elements of SIGTRAN adaptation layers apply with the following exceptions and restrictions. The considerations 
in this clause are common to the present document, TS 102 142 [6] and TS 102 143 [7]. 



4.1 Transport protocol 



The protocol underlying the adaptation layer for transport of SS No. 7 signalling information in IP networks shall be 
SCTP. 

4.2 SCTP considerations 

The SCTP used shall conform to TS 102 144 [8]. 

The SCTP payload protocol identifier for messages pertaining to an adaptation layer shall be the one assigned by lANA 
for that layer. Adaptation layer messages received with neither the lANA payload protocol identifier nor payload 
protocol identifier equal to shall be silently discarded. 

Unordered user messages shall not be used. 



4.3 National options 



No national options excluded by ETSI standards shall apply to the present document. 



4.4 Application Server mode 

The Broadcast mode shall not be used. 



£75/ 



7 ETSI TS 102 141 VI. 1.1 (2003-05) 

4.5 Application Server state handling 

If multiple Application Server Processes (ASPs) are used within the AS, the AS shall be considered active when the 
first ASP becomes active, and shall remain active until the last ASP becomes inactive. 

4.6 Dynamic registration 

Dynamic registration shall not be used for configuration management. The configuration of the system shall be 
modified only by the management system, and not by the protocol itself. 

4.7 IVIessage distribution to the Application Server 

The key to enable messages to be distributed to the appropriate AS shall have a granularity no smaller than is allowed 
by the management messages appropriate to that layer. 

4.8 Receipt of unrecognized messages 

If a message with an unrecognized message class is received, a Management Error message shall be returned with Error 
Code "Unsupported Message Class". 



5 Considerations applicable to M2UA 

5.1 M2UA procedures 

The M2UA procedures shall be as defined in RFC 3331 [2] augmented by ITU-T Recommendations Q.701 [3], 
Q.702 [4] and Q.703 [5] as modified by EN 300 008-1 [1], except where otherwise defined below. 

5.2 National options 

No national options excluded by EN 300 008-1 [1] shall apply to the present document. 

5.3 Dynamic registration 

Dynamic registration of Link Keys shall not be used for configuration management. The configuration of the system 
shall be modified only by the management system, and not by the protocol itself. 

5.4 Message distribution to the Application Server 

No special considerations for message distribution to the Application Server apply for M2UA. 

5.5 Using of the terms MGC (Media Gateway Controller) and 
ASP (Application Server process) 

The terms "MGC" and "ASP" have the same meaning in the present document. 
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Modifications to RFC 3331 



Modifications to RFC 3331 [2] are listed according to the sections and subsections of RFC 3331 [2]. 

Section 1 Introduction 

ANSI references do not apply. Add a reference EN 300 008-1 [1]. 

Subsection 1.3 M2UA Overview 

ANSI references do not apply. Add a reference EN 300 008-1 [1]. 

Subsection 1.3.1 Example - SG to MGC 

SCTP shall be used as the transport protocol for M2UA. TCP shall not be used as the transport protocol for M2UA. 

Subsection 1.3.3 Client/Server Model 

The SGP shall be able to support SCTP server operation and the ASP shall be able to support SCTP client operation. 
Support of both SCTP client and SCTP server operation at the ASP or SGP is optional. 

Subsection 1.4.2 Support for communication between Layer Management modules on SG and MGC 

NOTE: M-ERROR is a primitive, not a message. 

Subsection 1.4.3 Support for management of active associations between SG and MGC 

The M2UA layer shall inform its local Layer Management of the status of its underlying SCTP associations. This is 
done by use of the M-SCTP_STATUS primitive. 

The Layer Management shall inform the M2UA layer of an AS/ASP status (i.e. failure, active, etc.) so that messages 
can be exchanged to stop traffic to the local M2UA user. 

Subsection 1.5.2 Support for the management of SCTP associations between the SGPs and ASPs 

If instructed by the local management, the M2UA layer shall initiate the establishment of a SCTP association to a peer 
M2UA node. 

The M2UA layer shall also inform the local management of the status of underlying SCTP associations using the 
M-SCTP_STATUS request and the indication primitive. 

Also the M2UA layer shall inform the local management of the change in status of an ASP or AS. 

Subsection 1.5.3 Status of ASPs 

The M2UA layer shall inform the local management of the change in status of ASP or AS. 

Subsection 1.5.5 Seamless SS7 Network Management Interworking 

The M2UA on the SGP shall pass an indication of unavailability of the M2UA-User (MTP3) to the Local Management, 
if the currently active ASP moves from the ACTIVE state. The actions taken by M2UA on the SGP with regards to 
MTP Level 2 shall be in accordance with EN 300 008-1 [1]. 

Subsection 1.5.6 Flow Control / Congestion 

When M2UA is informed of IP congestion onset or congestion abatement by the SCTP, the actions taken by the SG 
shall be in accordance with EN 300 008-1 [1]. 

Subsection 1.6.4 Definition of Layer Management / M2UA Boundary 

M-SCTP_RELEASE indication primitive shall also be used by the SGP to inform Layer Management that the SCTP 
association has failed. 
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The M-SCTP_STATUS confirmation primitive shall be added: 

Direction: M2UA -^ LM 

Purpose: M2UA responds with the status of a SCTP association. 

The M-ASP_STATUS confirmation primitive shall be used instead of M-ASP_STATUS indication: 

Direction: M2UA -» LM 

Purpose: M2UA reports the status of a local or remote ASP. 

The M-AS_STATUS confirmation primitive shall be used instead of M-AS_STATUS indication: 

Direction: M2UA -^ LM 

Purpose: SG reports the status of an AS. 

M-LINK_KEY_REG primitives and M-LINK_KEY_DEREG primitives shall not be used. 
The following primitives shall be added: 
M-ASP_UP indication 

Direction: M2UA -^ LM 

Purpose: M2UA reports it has successfully processed an incoming ASP Up message from its peer. 

M-ASP_DOWN indication 

Direction: M2UA -^ LM 

Purpose: M2UA reports it has successfully processed an incoming ASP Down message from its peer, or the 

SCTP association has been lost/restart. 

M-ASP_ACTIVE indication 

Direction: M2UA -^ LM 

Purpose: M2UA reports it has successfully processed an incoming ASP Active message from its peer. 

M-ASP_INACTIVE indication 

Direction: M2UA -^ LM 

Purpose: M2UA reports it has successfully processed an incoming ASP Inactive message from its peer. 

M-AS_ACTIVE indication 

Direction: M2UA -^ LM 

Purpose: M2UA reports that an AS has moved to the AS-ACTIVE state. 

M-AS_INACTIVE indication 

Direction: M2UA -^ LM 

Purpose: M2UA reports that an AS has moved to the AS-INACTIVE state. 

M-AS_DOWN indication 

Direction: M2UA -^ LM 

Purpose: M2UA reports that an AS has moved to the AS-DOWN state. 



£75/ 



10 ETSI TS 102 141 VI. 1.1 (2003-05) 

M-ERROR_OCC indication 

Direction: M2UA -» LM 

Purpose: M2UA reports an error condition to LM. 

Subsection 3.1.3 Message Class 

MGMT messages shall use SCTP stream 0, ASPSM messages shall use stream (apart from BEAT and BEAT ACK 
which can use any stream), ASPTM messages shall use a traffic stream, MAUP messages shall use any but stream 0. 

Interface Identifier Management (IIM) messages shall not be used. 

If an Interface Identifier Management (IIM) message is received an Error (ERR) message shall be returned with Error 
Code "Unsupported Message Class", the IIM message shall be discarded and a report made to Layer Management. 

Subsection 3.1.4 Message Type 

Application Server Process State Maintenance (ASPSM) messages: 

BEAT shall not be sent. If a BEAT is received, a BEAT ACK shall be sent in response. If a BEAT ACK is received, it 
shall be discarded and a report made to Layer Management. 

Interface Identifier Management (IIM) Messages: 

Interface Identifier Management (IIM) messages shall not be used. 

If an Interface Identifier Management (IIM) message is received an Error (ERR) message shall be returned with Error 
Code "Unsupported Message Class", the IIM message shall be discarded and a report made to Layer Management. 

Subsection 3.1.5 Message Length 

The message shall not be longer than a MTP3 message EN 300 008-1 [1] plus the length of the common and M2UA 
message headers. 

Subsection 3.2 Message Header 

The text formatted Interface Identifier shall not be supported. 

Figure 4 and the paragraph below it do not apply. 

Subsection 3.3.1.1 Data 

Data messages with TTC PDU parameters shall not be used. 

The Length of the Protocol Data shall not exceed the length of a MTP-User application message EN 300 008-1 [1]. 

Subsection 3.3.1.3 Establish (Request, Confirmation) 

When the ASP sends a M2UA Establish Request message, the ASP shall start a timer (value T1h-T2h-T3h-T4 of ITU-T 
Recommendation Q.703 [5]). 

Subsection 3.3.1.5 State Request 

The following State Requests shall not be used: 

• STATUS_LPO_SET. 

• STATUS_LPO_CLEAR. 
Subsection 3.3.1.6 State Confirmation 

The following State Confirmations shall not be used: 

• STATUS_LPO_SET. 

• STATUS LPO CLEAR. 



£75/ 



11 ETSI TS 102 141 VI. 1.1 (2003-05) 

Subsection 3.3.1.8 Congestion Indication 

Discard Status parameters in the Congestion Indication message shall not be used. 

The LEVEL_1 and LEVEL_2 values for Congestion Status shall not be used. 

Subsection 3.3.1.11 Retrieval Indication 

TTC Data Messages shall not be used. 

Subsection 3.3.2.5 Heartbeat (BEAT) 

Heartbeat message is not required. BEAT shall not be sent. 

Subsection 3.3.2.6 Heartbeat Ack (BEAT ACK) 

Heartbeat Ack message is not required. If a BEAT ACK is received, it shall be discarded and a report made to Layer 
Management. 

Subsection 3.3.2.7 ASP Active (ASPAC) 

Text formatted Interface Identifier shall not be used. 

The format for the ASPAC message using text formatted (string) Interface Identifiers shall not be used. 

The traffic mode type parameter Broadcast shall not be used. 

The algorithm used in the SGP for load sharing traffic shall take into account SS7 message sequencing constraints. 

Text formatted Interface Identifiers shall not be used. 

Subsection 3.3.2.8 ASP Active Ack 

Text formatted Interface Identifiers shall not be used. 

The traffic mode type parameter Broadcast shall not be used. 

Subsection 3.3.2.9 ASP Inactive (ASPIA) 

Text formatted Interface Identifiers shall not be used. 

Subsection 3.3.2.10 ASP Inactive Ack 

Add "(ASPIA Ack)" at the end of the subsection title. 

Text formatted Interface Identifiers shall not be used. 

Subsection 3.3.3.1 Error (ERR) 

The text based Interface Identifiers shall not be used. 

Subsection 3.3.3.2 Notify (NTFY) 

Notify message with text-formatted Interface Identifiers shall not be used. 

Subsection 3.3.4 IIM Messages 

Interface Identifier Management (IIM) messages shall not be used for configuration management. 

Subsection 3.3.4.1 Registration Request (REG REQ) 

REG REQ message shall not be used. 

Subsection 3.3.4.2 Registration Response (REG RSP) 

REG RSP message shall not be used. 
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Subsection 3.3.4.3 De-Registration Request (DEREG REQ) 

DEREG REQ message shall not be used. 

Subsection 3.3.4.4 De-Registration Response (DEREG RSP) 

DEREG RSP message shall not be used. 

Subsection 4.2 Receipt of Primitives from the Layer Management 

NOTE: An ASP (not SGP) initiates the establishment of the SCTP association. 
Subsection 4.2.1 Receipt of M2UA Peer Management Messages 

All ASP state changes shall be reported to the Local Management. 

Heartbeat procedures are not required. BEAT shall be not sent. If a BEAT is received, a BEAT ACK shall be sent in 
response. If a BEAT ACK is received, it shall be discarded and a report made to Layer Management. 

Subsection 4.3.2 AS States 

AS and ASP configuration data shall be inserted by the management system, and shall not be created dynamically. 

If multiple Application Server Processes (ASPs) are used within the AS, the AS shall be considered active when the 
first ASP becomes active, and shall remain active until the last ASP becomes inactive. 

Subsection 4.3.3 M2UA Management Procedures for Primitives 

Whether the re-establishment of the SCTP association is done by M2UA itself, or by the Layer Management, is 
implementation dependent. If it is done by the M2UA layer automatically, the Layer Management shall be informed. 

Subsection 4.3.4.1 ASP Up Procedures 

Whether the initiation of the ASP Up message is done by a M2UA management function itself, or by the Layer 
Management, is implementation dependent. If it is done by the M2UA management function automatically, the Layer 
Management shall be informed. 

When the ASP sends an ASP Up message it starts timer T(ack). If the ASP does not receive a response to the ASP Up 
message within T(ack), the ASP shall inform Layer Management with a M-ASP_UP confirm primitive carrying a 
negative indication. T(ack) is provisionable wih a default of 2 s. 

The ASP shall wait for the ASP Up Ack message before sending any other M2UA messages (e.g. ASP Active). If the 
SGP receives any other M2UA messages before an ASP Up message is received (other than ASP Down - see 
section 4.3.4.2), the SGP shall discard them. 

Subsection 4.3.4.2 ASP Down Procedures 

Whether the initiation of the ASP Down message is initiated by a M2UA management function itself, or by the Layer 
Management, is implementation dependent. If it is done by the M2UA management function automatically, the Layer 
Management shall be informed. 

Dynamic registration procedures shall not be used. 

At the ASP, the ASP Down Ack message received is not acknowledged. Layer Management is informed with a 
M-ASP_DOWN confirm primitive. If the ASP receives an ASP Down Ack without having sent an ASP Down message, 
the ASP shall consider itself as in the ASP-DOWN state. If the ASP was previously in the ASP- ACTIVE or 
ASP_INACTIVE state, the ASP shall then initiate procedures to return itself to its previous state. 

When the ASP sends an ASP Down message it shall start timer T(ack). If the ASP does not receive a response to the 
ASP Down message within T(ack), the ASP shall inform Layer Management with a M-ASP_DOWN confirm primitive 
carrying a negative indication. T(ack) is provisionable, with a default of 2 s. 

Subsection 4.3.4.3 ASP Active Procedures 

Whether the initiation of the ASP Active message is initiated by a M2UA management function itself, or by the Layer 
Management, is implementation dependent. If it is done by the M2UA management function automatically, the Layer 
Management shall be informed. 
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The SGP shall discard any Data messages messages received before the ASPAC. 

ASP shall not send MAUP messages until it receives the ASPAC Ack. 

If an "out-of-the-blue" ASP active message is received, it shall be discarded and the report made to Layer Management. 

When the ASP sends an ASP Active message it shall start timer T(ack). If the ASP does not receive a response to the 
ASP Active message within T(ack), the ASP shall inform Layer Management with a M-ASP_ACTIVE confirm 
primitive carrying a negative indication. T(ack) is provisionable, with a default of 2 s. 

Broadcast mode of Application server traffic handling in the SGP M2UA layer shall not be used. 

The algorithm used in the SGP for load sharing traffic within an AS across ASPs shall take into account SS7 messages 
sequencing constraints. 

If multiple Application Server Processes (ASPs) are used within the AS, the SGP shall direct traffic to the AS when its 
first ASP becomes active. 

Subsection 4.3.4.4 ASP Inactive Procedures 

Whether the initiation of the ASP Inactive message is initiated by a M2UA management function itself, or by the Layer 
Management, is implementation dependent. If it is done by the M2UA management function automatically, the Layer 
Management shall be informed. 

In the case of a Load-share mode AS, the SGP moves the ASP to the ASP-INACTIVE state and the AS traffic is 
re-allocated across the remaining ASPs in the state ASP-ACTIVE, as per the load sharing algorithm currently used 
within the AS. A Notify message ("Insufficient ASP resources active in AS") shall be sent to all inactive ASPs, if 
required. An ASP Inactive Ack message is sent to the ASP after all traffic is halted and Layer Management is informed 
with a M-ASP_INACTIVE indication primitive. 

Broadcast mode AS shall not be used. 

At the ASP, the ASP Inactive Ack message received is not acknowledged. Layer management is informed with a 
M-ASP_INACTIVE confirm primitive. If the ASP receives an ASP Inactive Ack without having sent an ASP Inactive 
message, the ASP shall now consider itself as in the ASP-INACTIVE state. If the ASP was previously in the 
ASP-ACTIVE state, the ASP shall then initiate procedures to return itself to that state. 

Subsection 4.3.4.5 Notify procedures 

NOTE: Notify is used to report any ASP state change. 

Broadcast mode shall not be used. 

Subsection 4.3.4.6 Heartbeat procedures 

Heartbeat message shall not be used. If a Heartbeat message is received, a Heartbeat Ack shall be sent in response. If a 
Heartbeat Ack is received, it shall be discarded and a report made to Layer Management. 

Subsection 4.4 Link Key Management Procedures 

The Link Key Management procedures shall not be used for configuration management. The configuration of the 
system shall be modified only by the management system, and not by the protocol itself. 

Link Key Management messages shall not be sent. If a Link Key Management message is received an Error (ERR) 
message shall be returned with an Error Code "Unsupported Message Class", the Link Key management message shall 
be discarded and a report made to Layer Management. 

Subsection 5.1.2 Single ASP in an Application Server (1h-0 sparing) with Dynamic Registration 

Dynamic registration of an Interface Identifier (s) shall not be used. In this case, the scenario 5.1.2 will not apply. 
Subsection 5.3.3 Set and Clear Local Processor Outage 

MGC shall not set a Local Processor Outage condition. 
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Subsection 5.3.6 SS7 Link Changeover 

An example of the message flow for an error free changeover: 

• The (seq_num = 0) Sequence Number field in the (ACTION_RTRV_BSN) Action field of the Rtrv Req 
message shall not be used (see subsection 3.3.1.9). 

• The (seq_num = 0) Sequence Number field in the (ACTION_RTRV_MSGS) Action field of the Rtrv Cfm 
message shall not be used (see subsection 3.3.1.10). 

An example of the message flow for a request to drop messages (clear retransmission buffers): 

• Clr RTB Cfm messages between MTP2 and M2UA and between M2UA and MTP3 to confirm a request to 
drop messages shall be used. 

Section 7.0 Security considerations 

Security is out of the scope of the present document. 

Subsection 8.1 SCTP Payload Protocol Identifier 

It is recommended that for server operation the lANA registered port number for M2UA is set to 2904. SGPs may also 
use statistically configured SCTP port numbers. The payload protocol ID (2), for M2UA, shall be used. If an 
unrecognizable payload protocol ID is received, the message shall be silently discarded. 
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